U.S. Pat. No. 6,854,114 granted to Harlan Sexton et al is incorporated by reference herein in its entirety, as background. In this patent, Sexton describes multiple VM instances accessing a shared area. Referring to FIG. 1 attached hereto, three clients have established three sessions through a server. In session 1, a call that involves services provided by the virtual machine is currently being processed by a system thread using VM instance 1. In session 3, a call that involves services provided by the virtual machine is currently being processed by a system thread using VM instance 3. Both VM instance 1 and VM instance 3 share access to the shared state area, which in the illustrated embodiment includes data for Java class X. In session 2, no call is currently active. The call memory associated with any previous call has been discarded. Only the session memory of VM instance 2 remains allocated. Because session 2 is not currently processing a call that makes use of VM instance 2, VM instance 2 is not currently assigned to any system thread. The various VM instances instantiated within the server may actually be created and run in either separate processes, or using system threads.
VM instances of the type described above typically use a Java virtual machine interpreter (such as interpreter 110 in FIG. 2) which is responsible for interpreting Java byte codes. FIG. 2 is described in U.S. Pat. No. 7,032,216 granted to Dmitry Nizhegorodov, which patent is hereby incorporated by reference herein in its entirety, as background. In this patent, Nizhegorodov states that, in addition to the byte codes, a native compiler produces translated code 120, which is also loaded in the virtual machine. Preferably, the translated code 120 is configured to interact with interpreter 110 to support an execution model that mixes byte-interpreted and natively compiled classes. Thus, routines in translated code 120 may call routines that are interpreted, and interpreted routines may call translated code 120 routines, thereby providing call interoperability. Virtual machine services 130 are provided for supplying such services as dynamic memory management and garbage collection. Translated code 120 is generated to use the API of virtual machine services 130 (which is used by interpreter 110) by passing the context parameter or handle to the routines of the virtual machine services 130.
Run-time environment 140 of FIG. 2 provides base functionality of the virtual machine, interfacing with the underlying operating system and relational database system. Run-time environment 140 may also include a meta-object system such as that described in U.S. Pat. No. 6,782,532 granted to Sexton, et al., which patent is also hereby incorporated by reference herein in its entirety, as background. Accordingly, translated code 140 is configured to interact with run-time environment 140 in the same way as virtual machine services 130, for example by laying out objects in the same way and using the same meta-object system. Runtime environment 140 of the type described above is normally responsible for managing memory for objects that are created and destroyed during the execution of a program.
One technology employed by several Java Virtual Machines (JVMs) to run Java code is dynamic compilation, which is also called Just-in-Time (JIT) compilation. In such a scenario, Java bytecodes are compiled into native machine code, on demand. This allows Java bytecodes to be interpreted by the JVM until they are found to be heavily used at which time they are compiled by the JIT compiler. However, to the inventors knowledge, a JIT compiler normally discards any native code that has been dynamically created, when an instantiation of the virtual machine (VM) ends. Although discarding the native code is simpler, it does require at least some of the same code to be recompiled in a new instantiation that may start up at a later time. To share compiled code across temporally-spaced apart VM instantiations, the inventors note that it is necessary to persist the compiled code.
U.S. Pat. No. 6,973,646 granted to Bordawekar et al. is incorporated by reference herein in its entirety as background. Bordawekar describes generating “persistent code images” prior to program execution based on static compilation or dynamic compilation from a previous run, and then, adapting those images during program execution. According to Bordawekar, the code images are stored a file system in files of extension “.qnx”. Note that, Bordawekar requires generation of adaptation annotations and their use in adapting the persisted code images to an execution context, followed by generating executable (i.e. native) code prior to its execution. See Bordawekar's Abstract. Bordawekar's adaptation is further described in column 10, wherein a sample instruction to load “stats.count” is adapted to yield six instructions shown at lines 40-50 in column 10 of Bordawekar's patent. The current inventors find that such adaptation of instructions from a code image by Bordawekar has the benefit of generating more optimal code in some situations (e.g. inserting extra code only for class initialization), but has the drawback of being slow to start execution.